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The purpose of this research was to investigate the gen¬ 
eration of machine code from high-level programming language. 

The following steps were undertaken: 

1) Choose a high-level programming language as the source 
language and a computer as the target computer. 

2) Examine all stages during the compiling of a high- 
level programming language and all data sets involved in 
the compilation. 

3) Discover the mechanism for generating machine code and 
the mechanism to generate more efficient machine code from 
the language. 

3) Construct an algorithm for generating machine code for 
the target computer. 

The results suggest that compiler is best implemented in a 
high-level programming language, and that SCANNER and PARSER should 
be independent of target representations, if possible. 
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CHAPTER I 


INTRODUCTION 

Kl. The Problem Definition 

The purpose of this research Is to Investigate the 
generation of machine code from high-level programming 
languages; In particular, having proposed a model of such 
processing, to answer the questions 5 

Given a high-level programming language, how can the 
target computer code be generated? 

How can a more efficient machine code for the target 
computer be generated? 

• 

1*2* Procedure 

In order to accomplish the purpose of the research, the 
following steps were undertaken; 

1) Choose a high-level programming language to be 
the source language and a computer as the target 
computer» 

2) Examine all stages during the compiling of a 
high-level programming language and all data sets 
involved In the compilation, 

3) Discover the mechanism for generating machine 


1 
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code and the mechanism to generate more efficient machine 
code from the language* 

4) Construct an algorithm for generating machine 
code for the target computer. 

1»3» Source Language and Target Computer • 

fhe FPL. (THIS PROGRAMMING LANGUAGE) programming 
language was chosen as the source language* Although it is a 
relative simple language, it Is complex enough to display 
many of the quality and implementation difficulties of more 
advanced high-level language. 

The FAIRCHILD F24 mini-computer was chosen as the 
target computer for the model, since it is a 
memory-oriented, high-speed, general-pur pose digital 

computer v/ith flexible addressing abilities. 

Figure 1.1 is the system flow for generating machine 
code from the TPL programming language. 



TPL j 



* LISTING * 
************* 


FIGURE 1*1. System Flow for Generating Machine Code 
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1*4* Organization 

« This research is organized into eight chapters; the 
fi rst chapter provides a general description of the 
research* The second chapter describes the analysis stages 
during a language compilation* The third chapter describes 
the storage allocation algorithms used by high-level 
programming language. The fourth chapter discusses the 
function and algorithm for code generation. The fifth 
chapter examines several techniquees for generating 
optimized target machine code from high-level programming 
languages. The sixth chapter contains an description of This 
Programming Language, which is the source language of the 
model. The seventh chapter discusses the data bases which 
are involved in the generation of machine code from a 
high-level programming language. The last chapter contains 
the summary and conclusion. 



CHAPTER II 


ANALYSIS 

2.1» Introduct?on 

The purpose of the analysis during a compilation of a 
programming language is to translate the input source 
language into a intermediate form (usually a structure 
tree)(3); from this intermediate form the code generator 
creates the target machine code for the language. 

In this chapter different phases of analysis for 
compiling a language are depicted. 

2.2. Lexica] analysis 

The action of parsing the source program into proper 
syntactic classes is known as lexical analysis. The aim of 
the lexical analysis of the compiler is to take the input 
source language, which is presented in some form, and 
translate this into a string of tokens. We usually call this 
translator the “scanner 15 . The token stream which comes out 
of the scanner is the input to the parser, which is the 
processor in the syntax analysis phase during a language 
compi 1 ati on# 

5 
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2.2.1. Scanning 

Scanning is the major processing during the lexical 
analysis phase* Scanning involves finding the substrings of 
characters that constitute units called textual elements. 
These elements are the words* punctuation, single- and 
mu 11i-character operators, comments* sequence of spaces, and 
numbers of the source. 

For example, consider the following line from a PL/1 
program represented as a character stream. 

IF XX < 10 THEN YY = YY + 1 ; 

After scanning the program may he regarded as being in 
following form * ^ 

f 

IF XX <10 THEN YY = YY + I ; 

id..id..Top!.nI! id 11 iolopn idUopInIIop 

Where 'ID' means 'identifier', 'N' means 'integer', 
means 'space', and 'OP' means 'operator'. The 'space', the 
'identifier', the 'integer', and the 'operator' are textual 
elements. 

2.2.2. Lexical Grammars 

One can usually specify the textual elements of a 
programming language, its lexical level, with a regular 
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grammar or a regular expression, or most conveniently with a 
mixture of the two in the form of a transduction grammar, 
for example, consider the following grammar- 

<text>=<ioentifer><space>!<integer><space> 

<IDENT IF IER> : 2 ”<LETTER>j <LETTER><LETTER-0IGIT> 
<LETTER~DIGIT>::=<LETTER>J<OIGIT> 
<INTEGER>:s=<OIGIT>!<INTEGER><OIGIT> 


<LETTER> 2 :=AlBi.......... |Z 

<0IGIT>:2=o!l|2|..........|9 


<SPACE >' ' i' '<SPACE> 

This grammar describes a very simple lexicon containing 
identifiers, integers, and spaces. Identifiers and integers 
must be separated from each other by at least one space. 

2.2.3* Finite-state Machine 

To display more clearly the structure of scanner for 


the lexical 

gr a rnmar i n section 

2.2.2., I 

present 

r ts 

f 1 nfte-state 

machined ) diagram on 

Figure 2.1. 

In fact. 

the 


scanner procedure is a simulation of a finite-state machine 
which breaks the source program into tokens(l). In Figure 
2.1. Two states noted by *7* need look-ahead sets(2) to 
determine read-reduce(2) decisions. The finite-state machine 
simulation is done in the usual manner with two tables(4) 2 






I 

i 


START 


» 

i 


< 


V_ 


FIgure 


-> <SPACE> 


4 

i 

i 

i 


< - 

! <LETTER> t 
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2*1* Finite-State Machine for Lexica] Analysis 
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one table which defines the next state function, and another 
table which defines the action associated with each state 
transition. 

The scanner can be implemented directly as an 
executable program. However, it is noteworthy that scanners 
frequently have states with direct loops, such as states 
blank, letters, and digits. Such states should be 
Implemented as fast as possible since they typically do the 
bulk of the scanning. 

2.3. Error Recovery in Lexical Analysis 

While scanning a textual element, the scanner is always 
either in a context in which it has had some left context 
that must be matched by the some right context (e.g., the 
right parenthesis must matched the left parenthesis) or It 
is in a context that may legally end at any point. In the 
latter case, characters in error show up as the beginning of 
the next textual element and can usually be skipped or 
replaced with a blank to permit continuation of the 
processing. In the former case a scan to the end of the 
current Hne is usually done in order to try to find the 
desired right context. If found, the intervening text can be 
considered part of the current textual element? otherwise. 
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r-i. 


the rest of the line is usually best skipped and the scanner 
is best restored to its initial state. 

After detecting and reporting an error, a module may 
either attempt to repair it (so it is not seen by subquent 
modules) or pass it along. Each approach has its problems? 
If a module is to be truly an error sink, it must ensure 
that none of the effects of the error it has repatred can 
‘propagate. Conversely, if it does not filter out all errors, 
then all subquent modules must: be prepared to deal 
reasonably with them (without generating too many further 
messages). 

In many compilers, a single error can trigger a whole 
avalanche of messages on the unsuspecting error? this is 
very nearly as unacceptable as quitting the scan after the 
first error(5). 

2.4. Syntax Analysis 

The main aim of the syntax analysis phase during a 
language compilation is to take the token string produced by 
the scanner in lexical analysis phase, and to use some 
parsing algorithm to verify that the token string consists 
of a legal string. In addition, it is required to collect 
Information about the language, and produce as output a 
structure tree which could be code which is ready to be 
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executed or Interpreted, but is more likely to be a 
structural representation of the token string which will be 
used to generate code* 

2*5* Error Recovery in Syntax Analysis 

Syntactic analysis also notes syntactic errors and 
assures some sort of recovery so that the compiler can 
continue to look for other compilation errors* 

A syntactic error is discovered when the parser can 
take no further valid parsing actions, given the current 
state of the parser (the stack) and the current input 
symbol. Recovery thus requires changing the stack, the 
input, or both* The change may take the form.of deletions or 
insertions (a substitution is a deletion and a insertion)* 

Gries(2) points out that changes to the stack are 
particularly dangerous, since semantic routines will have 
been invoked for the parsing actions leading to the current 
stack, and the parser can not safely undo or modify the 
effects of these actions* 

Lein?us(5) was consider augmenting the syntactic 
description of a language by a number of error productions, 
describing common errors, as so that recovery can be 
subsumed under normal parsing* For this strategy to be 



effective, several problems must be deal with* the 
compi1er-wr1 ter must ensure that he has really included 
enough error productions to cover the common errors; since 
so many different: errors are possible, the error productions 
may substantially enlarge the grammar (and hence the 
parser); it is difficult to include error productions 
without making the grammar ambiguous, 

2.6, Semantic Analysis 

The purpose of semantic analysis is to derive an 
evaluation procedure from the structure tree of an 
expression and the attributes of its components. 

An evaluation procedure is a seciuence of primitive 
operations on primitive operands, and is completely 
specified by the definition of the source language. The 
semantic analyzer must deduce the attributes of the various 
components of a structure tree, ensure that they are 
compatible, and then select the proper evaluation procedure 
from those available. The input to the semantic analyzer 
consists of the structure tree which specifies the 
algorithm, and the dictionary which provides attribute 
information. 

Two transformations, attribute propagation and 
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flattening, are performed in semantic analysis(6)s 

1) Attribute propagation* 

Attribute propagation is the process of deriving 
the attributes of a structure tree from those of its 
components. 

2) Flattening^ 

Flattening is the process of transforming a 
structure tree into . a sequence by making explict the 
order in which the operators are executed (in order to 
produce optimized code from the code generator). 
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CHAPTER III 


STORAGE ALLOCATION 

3.1. Introduction 

High-level programming languages with different 
features require different types of storage management, in 
which a hierarchy can be distlnguished* at the bottom end is 
the static allocation scheme for a language like FGRTRAN(5), 
in which it ?s possible to know the address that each object 
will occupy at the run time. At the next level comes the 
stack techniques for languages like ALG0L60{1), where space 
is allocated on a stack at block entry and released at block 
exit. Languages like PL/1(4) permit both types of storage 
management. 

3.2. Static Allocation 

In a static allocation scheme it must be possible to 
decide at compile time the address that each object will 
occupy at run time. This requires that the number and size 
of the possible objects be known at compile time. This is 
the reason why programming languages that use static 
allocation have constant bounds for arrays and procedures 
can not be recursive. 
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The process which the compiler goes through in doing 
storage allocation for a static language Is very simple; 
eluting the first pass of the text the compiler creates a 
symbol table in which are kept the name, type, size and 
address of each object encountered. During the later code 
generation phase, the address of each object is thus 
available for insertion into the object code. 

3.3. Dynamic Allocation 

Modern high-level programming languages allow recursive 
procedure calls, and this precludes any attempt at a static 
storage allocation scheme, since a variable which is 
declared and used with a recursive procedure may correspond 
to more than fane value at a given moment during the 
execution of the program. 

The usual storage model for a dynamic allocation is a 
stack, on which entry to a block or a procedure causes a new 
allocation, the space being freed at exit from the block or 
procedure. The use of a stack to model nested structures is 
a standard device(2). 

3.4. Storage Allocation For Arrays 

In a programming language in which the size of an array 
is known at compile time, its space can be allocated 



17 


statically ? 

For example * 

A(5,10) 

A is a array of size of 5x10 and 50 consecutive storage 
locations will be reserved? 

A(1,1),A(1,2).•A(5,1),A(1,2)..A(5 V 2)..A(5,10) 

When making a reference, element A(I,J) is to be found 
in location 

(J-1)*5+I-1 from the start of the array. 

(r ■ 

In general, given an array A with bounds Bi ? 

/ 

Element A(Ilil2.. In) is to be found at location 
(..(( In-1) * B(n-l)-l) * B(n-2)+..+ 12-1) * BI + 11-1 

In a programming language in which the limits of 
boundrles of a array is not known at compile time, storage 
allocation for a array must dynamic. 

3.5. Storage Allocation for Temporary Variables 

A major problem of storage allocation arises when 
considering how to allocate storage for temporary variables 
required for partial results during a compilation. These 
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variables are not defined by the language but by the 
compiler. How many are required and how storage is allocated 
is‘comp 1etely dependent upon the compiler(3). 

The code generator algorithms did not concern 
themselves with how storage for the temporary variables 
should be allocated. They can be thought of as taking a new 
variable name from an infinite set of unused names each time 
a temporary variable is required by the algorithm. The 
storage allocation algorithm has to allocate storage for 
these variables in such a way that the minimum number of 
storage locations Is required. 

Variables having completely disjoint ranges at 
execution time can be allocated the same location. The usage 
range of a variable Is defined as the sequence of code 
interval between the initial definition of the vaule of a 
variable and its last use. There are two algorithms for 
finding the usage range of a variable(3) 2 

3.5.1. Backward Scan Algorithm 

Consider a set of variables 5 VI,V2,V3....... Vn . For 

each variable Vi, an statement is defined 5 

ST Vi 

which initially sets a value to the variable and 
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Indicates the start of the range for VI* 
A statement 2 


U VI 


Is defined 

which indicates a 

subsequent use of 

thi s 

variable* The 

1 ast 

instruction of 

this type using 

Vi 

indicates the end of' the range for Vi* 



A sequence 

of 

code produced 

by code generator 

then 

consists of a 

set 

of instructions 

independent of 

the 


variable VI, together with the orders of the two statements 
defined above which use the variables VI , for 1=1 to n. The 
problem Is to allocate storage to the VI so that the minimum 
number of location is required* The assumption Is that a 
variable Is no longer required after the last appearance of 
It In the sequence. In this sense It assumed that the 
sequence is completed. Once a variable is no longer 
required. Its storage location may be re-allocated to 
another variable not yet defined. It is assumed that this 
sequence of Instructions does not contain any entry points 
other than at the top and that control passes straight 
through the sequence, leaving at the bottom (no branches). 

Consider the arithmetic expression * 
(A+B*C)/(F*G-(D+E)/(H+K)) 

The code generated for the expression might be as 
follows for the IBM 3602 
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L H 
ADO K 
ST VI 
L D 
ADD E 
DIV VI 
ST V2 
L F 
MPY G 
SUB V 2 
ST V3 
L B 
MPY C 
ADD A 
DIV V 3 


The names VI,V2 and V3 would be taken from the set of 
unused names* As far as storage allocation is concern the 
squence of code can be written ( ST - Store, U = Use): 


ST VI 
U VI 
ST V2 
' U V2 
ST V3 
U V3 

As the last of each variable appears before the next is 
defined, it is obviously that one storage is sufficient. 


The general algorithm will be : 


Scan the sequence of instructions from the end 
backward. For each instruction of the type U Vi (1=1 to 
3), if no storage location has been allocated to Vi, take 
the top free storage location from the stack and assign 
it to Vi and replace Vi in the instruction by the address 
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/ 

of the storage location. For each instruction ST Vi, if 
no storage location has been allocated to Vi, then either 
there is an error or this order is redundant, as this 
implies that there are no subsequant uses of the 
variable. If storage has been allocated to Vi, then 
replace Vi In the instruction by the address of the 
storage location and, as this is the’first time use of 
the variable VI, the location may now be returned to the 
free store stack, as it is no longer required. 

3.5.2. Forward Scan Algorithm 

In the forward scan, the ST instruction defines the 
start of the range. A count of the number of uses of each 
variable has been kept and is used to find the last use of a 
variable so that the end of the usage range also can be 


found. 
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CHAPTER IV 


CODE GENERATION 

Inferoduction 

A source language definition specifies the evaluation 
procedure for the constructs of the language in terms of a 
set of primitive operators and operands provided for this 
purpose. Code generation is the process of an evaluation 
procedure in terms of the primitive of a particular target 
computer(5). 

The basic approach is to simulate the evaluation 
procedure in the environment provided by the target computer 
(with its register organization and addressing structure). A 
symbolic description of the run time contents of the 
environment is maintained by the code generator. When the 
evaluation procedure indicates that the contents should be 
altered, then code to perform the alteration is emitted and 
the description is updated. The data for the code generator 
are structure trees. The evaluation procedure specifies the 
sequence in which the nodes of a structure tree are to be 
considered when performing the evaluation, and this sequence 
is largely independent of the particular target computer. 
The structure tree is traversed by the semantic analyzer. 
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which considers the entire subtree before deciding upon the 
best, sequence of operations to perform. Thus the code 
generator input is a sequence of tokens specified by the 
nodes of the structure tree. 

4.2* A Model for Code Generator 

The code generator does not have arbitrary access to 
the structure tree, and must therefore operate on the basis 
of limited infcrmation(5). The model which I have chosen 
consists of two parts* 

1. A push store transducer, which maintains the 
contextual information that can be derived from the 
sequence of input tokens. 

2. A target computer machine code generator, which 
maintains the run-time contents of the environment and 
produces sequence of target computer instructions to 
implement the abstract primitives. 

Hopgood(2) terms these components the translator and 
the coder respectly. 

The transducer passes a sequence of tree structures to 
the code generator, each consisting of an operator and its 
associated operands. Each command is interpreted by the code 
generator ?n the light of the object environment which 
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exists at that point In the execution of the program. It 
generates appropriate code and the updates the environment 
to‘reflect effect of that code. 

4.2.1. The Transducer 

A pushdown store transducer has four components(5) : an 
input, an output, a finite-state control and a pushdown 
store. The input models the stream of tokens which encodes 
the structure tree, and the output models the abstract 
instructions which will be delivered to the code generator. 
The finite-state control and the pushdown store encode the 
limited contextual information derived from the sequence of 
input tokens. 

Information pertaining to the ancestors of the current 
nodes, and the status of the current node itself, is encoded 
by the finite state control. The pushdown store contains 
information derived from subtrees which have been completely 
traversed. After all subtrees whose roots are descendants of 
a particular node have been traversed, their entries are 
deleted from the pushdown store and replace by a single 
entry for the entire tree rooted at that node. Information 
from the pushdown store Is used to identify the operands of 


an operator. 
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4.2*2. Code Generator 

In order to interpret the primitives of the source 
language in terms of the target machine, the code generator 
maintains descriptions of the values being manipulated and 
of the target machine environment. A particular value may be 
represented in many different ways in the target computer, 
and the purpose of the value image is to specify the current 
representation of each value* Similarly, the registers of 
the target computer may contain many different values during 
execution, and the purpose of the machine environment ?s to 
specify the current contents of each register. 

A value comes under the control of the code generator 

yf'' • 

when the transducer requests simulation of an operand token, 
giving the current transducer state as an argument. At that 
point the code generator creates an entry for the operand 
and links it to the machine environment. Values pass out of 
the control of code generator when they are used as 
operands. This is signalled when the transducer requests 
simulation an operator token giving the current state and 
one or more value as arguments. At that point the code 
generator deletes the operand entries from the value image, 
breaking any linkage to the machine environment. If a result 
Is specified, a description of the result value Is created 
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and linked to the appropriate entry In the target machine 
envfronment. 

In fact, the code generator producing a relocatable 
target machine code packet for each structure tree(3)„ 

4*3, Code Generation For Arithmetic Expressions 

To produce efficient machine codes for a arithemetic 
assignment statement Is one of the major problems in the 
compilation of a programming language(2). The efficiency of 
two compilers in the execution of a program will depend 
almost entirely on the code produced by the code generator. 

4.3*1* An Algorithm For Code Generation From A Tree Strusture 

A structure tree is a graph that consists of a 
collection of nodes and branches, which each branch 
connecting two nodes(2). 

Wa|te(5) defines a arithemetic expression as a 
structure tree written in linear form (figure 4.1.), with 
each node representing an elementary computation. A leaf of 
the tree represents a computation which can be carried out 
independently of all other nodes in the tree, while an 
Interior node represents a computation which requires as 
operands the results of the computations represented by its 


decendants. 
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A-3*(I+J)/2 


A), A Typical Expression 



B). The Equlvalant Tree for (A) 


Figure 4.1. The Meaning of an Expression 



One possible evaluation algorithm for this structue 


tree Is the following- 

1. Select any leaf and perform the computation which 
It represents* 

2. If the selected leaf Is the root, then exit. The 
result of the computation is the value of the tree. 

3. Otherwise, transmit the result to the parent of 
the leaf and delete the leaf from the tree. 

4. Repeat from 1. 

This procedure is strictly sequential, but nothing is 
mentioned about the order in which the leaves are selected. 

4.3.2. Anonymous Operands 

WaJte(5) points out that the reason for using an 
expression is to avoid naming each of the intermediate 
results created in the course of a computation. When a leaf 
of an arithemetic expression is evaluated, the result Is 
anonymous. The code generator is free to do what it well 
with these anonymous results because It has explicit control 
over the times at which they are created and the times at 
which they are freed, it does not need to worry about 
whether the programmer may access them unpredictably. 
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The following are three broad categories to process 
anonymous operands* 

1* Use no register 

All instructions take their operands from momory 
and return their results to memory, 

2. Use a single register 

Operators take thei r’ operand from the register 
and return their result to the register* 

3. Use mutlple registers* 

Binary operators take one operand either from a 
register or from memory and all operators return 
their result to a register. Some registers may be 
paired to provide an analog of the extension of a 
single-register machine, but all have essentially the 


some capabi 1 i t? es 
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CHAPTER V 


OPTIMIZATION 

5*1, Introduction 

Optimization is the term which is used to denote the. 
attempt by a translator to improve upon the description of 
the algorithm which was given by the programming language 
user. Optimization is most appropriate when the source 
language does not provide access to all of the facilities of 
the target computer(6). 

Any general approach to code optimization is severely 
limited by undecidability results(l) and by the lack of 
definitive opti ^ia lity criteria. The compiler 's optimizer 
therefore provides improvement (relative to some cost 
function), rather than true optimization(6). In order to 
avoid undecldab Ie equivalence questions, the improvement is 
carried out by applying a series of equiva3ence-preservi ng 
transformations to the original algorlthroCl). Each 
transformation is based upon information gathered from some 
region of the source program. 

In this chapter different techniques for optimization 
are depicted in detail. 
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5*2, Folding and Propagation 

When the value of the operands on an expression are 
known to the compiler, that expression can be folded 
(replaced by a single value)* When a variable is set to a 
value at compiler time, that value can be propagated 
(substitued for the variable) by the compiler, if the 
algorithm used by the compiler results in the same value 
that would result for evaluation at object time* 

5.3. Rearrangement 

The purpose of rearrangement is to reduce the amount of 
temporary storage required during the evaluation of an 
expression* This has the effect of speeding up the 
evaluation, because it may be possible to compute a value 
using only registers for temporary storage. 

Some number of anonymous operands must exist 
simultaneously during the evaluation of a given expression* 
This number depends upon the order in which the components 
of the expression are evaluated. 

The temporary storage requirements for a given 
expression are fixed. In order to lower the requirement, we 
must transform the tree structure of this expression into 
another which yields the same value but has a different tree 
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structure. 

For example, with the expression of Figure 5»1, we can 
transform the tree structure of the expression A*B+(C+D) 
from Figure 5.1(a) to obtain the tree sturcture of Figure 
5,1(b), which requires only a single temporary anonymous 
operand rather than two. This is valid only if the data type 
of (A*B) is the same as (OD); otherwise, transformation 
operation will have to be inserted to convert data types, as 
from single-precision to multiple precision, or from a fixed 
decimal number to a floating binary number. 

5.4. Redundant Elimination 

■ 'S' 

Code is redundant if the value which It computes is 
already available at the point where the code occurs. The 
method that is used to eliminate redundancy of a expression 
is that of finding common sub-expressions of a expression 
and eliminating the excessive use of temporary storages. 

Common sub-expressions elimination is an optimization 
which creates a directed acyclic tree(3) rather than a 
structure tree to describe the program. 

For example, given the expression of Figure 5.2, we can 
transform the tree structure of Figure 5.2(b) and create a 
directed acyclic tree of Figure 5*2(c) which retains only 
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A * B + (C -f D) 



(a). The Directed Tree Structure for the Expression 



(b). The Tree Strucrure Transformated from (a). 


Figure 5.1. Temporary Storage Requirements 
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I - J * (X + Y) + (X + Y) * K 

(a)„ An Expression With Common Sub-express I on 



(b). The Tree Structure for (a)* 



(c)* The Directed Acyclic Structure for (a). 


FIGURE 5.2* Eliminating a Common Sub-expression 
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one 'copy of each sub-express!cn. 

5*5* Strength Reduction 

Strength reduction is the general process of replacing 
an expensive (use relative mere CPU cycles) operation by a 
cheaper (use relative less CPU cycles) one and dose not 
alter the value of the expression* When a value is raised to 
a constant power It may be possible to replace the exponent 
by a series of multiplications- 

For example, the. polynomial 
X**4 + X**3 + X**2 + X + 1 

may be replaced by the expression 
X*(X*(X*(X+1)+1)+!)+! 

Another example is that the control variable of a loop 
is multiplied by an expression whose value remains constant 
over the loop; than that multipiication may be replaced by 
an addition. 

For example, the following code 
DO I = 3*X+Y TO Z ; 


END ; 
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may be replaced by 

TEMP = 3*X+Y ; 

% 

DO I = TEMP TO Z ; 

END ; 

5,6. Frequency Reduction 

Frequency reduction attempts to move operations from 
one part of the program which are entered frequently to the 
part which are entered rarely- The most important use of 
this transformation Is to remove invariant calculations from 
loops, on the assumption that the code inside a loop is 
executed more frequently than that surrounding the loop. 

For example • 

DO I = 1 TO 100 ; 

/* ASSUME THAT A, B, C, D ARE NOT EVALUATED */ 


X = A+(B*(C+D)) ; 


END ? 

may be replaced by 

X = A+(B*(C+D)) 5 


DO I = 1 TO 100 5 
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o « # « « • 


END ; 

5«7. Register Allocation 

Register allocation can be performed on the basis of • 
global flow analysis which provides the code generator with 
Information on the future use of values currently residing 
in registers; this type of allocation falls in the province 
of opt!mization(2). 

The so-called 'peephole opt I mization'(5), which avoids 
locally redundant fetches and stores of register contents. 
Is an instance of J nte11igent code generation. 

f 
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CHAPTER VI 


A DESCRIPTION OF TPL 


6.1* Introduction 

TPL. is a goto-less structured programmi ng(2) language 
with an unusual 1'/ complete set of control structure of the 
non-procedure variety* 

CASE and LEAVE statement are among the more unusual 
statements types found dn TPL* SELECT, CASE, LEAVE, 
IF-THEN-ELSE, UNLESS-THEN-ELSE, and REPEAT-WHILE staements 
are designed for structured programming in TPL. Functions 
are avaiable with zero or one argument and a single result. 

The syntax is PL/1 (1) -like except there are reserved 
words (APPENDIX 1). A usual set of arithmetic and comparison 
operations on integer numbers and one-character strings are 
included. Arrays are available. Input and output are 
unformatted. Storage allocation is static. 

The compiler of TPL is written in PL/1 to run on the 
IBM 360/370 computer. The compiler produces relocatable 
object code which can contain external references. 
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6,2. Basic Language Elements 

Identifier 

An indent!fier is a string of characters. The first 
character must be alphabetic. The remaining characters can 
be alphabetic, numeric, or the underscore character. An 
identifier may not contain embedded blanks. An identifier 
can be any length; however, the first six characters must be 
unique in Identifiers used as external function names. 
Identifiers are used as variable names, as control structure 
names, and as reserved words. 

Constants 

TPL has two types of constants. A numeric constant 
consists of up to five decimal digits optionally preceded by 
a sign. A character constant consists of one character 
preceded by a single quote. 

Spaces 

Spaces may not be embedded in identifiers or constants, 
but may be embedded anywhere and/or any number of spaces in 
the source program. 

Comment 

A comment is any character string started and ended 
with a bar character ('|'). A comment may extend over any 
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number of Input records and may appear anywhere a space rnay 
appear. 

•Examples• 

1. | THIS IS A COMMENT ! 

2„ SET A TO ! THIS IS A COMMENT ! B? 

Vectors 

A vector Is a array which defined by naming the vector 
and its length In a vector declaration statement. An element 
of a vector is chosen by following the vector name with an 
expression enclosed in parenthesis. 

Examples* 

1. VECTOR V(10), X(50) ; 

2. SET V(A+5) TO V(FUNCX(X-1)+B) ; 

6.3. Statements 

Statements are free form. Each statement is terminated 
by a semicolon. One statement can be spread over as many 
input records (cards) as necessary and one input record can 
contain several statements. 

Examples* 

1. SET A TO 0; SET B TO 0; SET C TO 0; 


2. SET A TO A+B; 



3. SET A TO A B 


* C 
D / E 


There are five types of statements in TPL. They are s 


1 . 

2 . 

3. 

4. 

5. 


Declaration statements 
Simple statements 

Statements that start a control structure 
Statements that end a control structure 
Statements that cause termination of a control 
Structure 


Type 3, 4, 5, are described iater in this chapter* 


6.3.1. Declaration Statement 


There are two types of declaration statements2 

1. EXTERNAL declaration statement 

2. VECTOR declaration statement 

All EXTERNAL declaration statements must proceed all 
other statements in the program. An EXTERNAL declaration 
statement specifies a list of function names which are 
external to the program being compiled. 

Examples2 

EXTERNAL EX1, EX2; 

All VECTOR declaration statements must proceed all 



other statements in the program except EXTERNAL declaration 
statements* A- VECTOR statement specifies a list of arrays 

and their lengths* 

Examples* 

'VECTOR A(10), V(20); 


6.3*2. Simple Statement 

There are three types of simple statements* 

1. SET 

2. INPUT 

3. OUTPUT 

The SET statement is the usual assignment statement* 

Examples* 

1* SET A TO 5; 

2. SET V(X*Y+Z) TO EUNC(J)+7; 

The INPUT statement causes input of the items In the 
list. An input list item can be a subcripted array or a 
simple variable. 

Examples* 

INPUT A, B(I), J, C(J); 

The OUTPUT statement causes output of the vaules of the 
items in the list. An output list item can be any 
expression. 


Examples* 



OUTPUT A+B*C, 17, D, 


, FUNC(X); 


There is no control over format for either INPUT or 
OUTPUT statements. 

6.4. Operations 

Arithmetic Operations 

A set of usual arithmetic operations are available in 
TPL. They are addition (+), subtraction (-), multiplication 
(*), and division (/) from left to right, except the 
following precedence of operations. 

Priority 1 

- prefix minus 
+ prefix pi us 

Priority 2 
J divide 
* multiply 

Priority 3 

- infix minus 
+ infix plus 

Relational Operations 

Relational operations are provided for use in IF and 
UNLESS statements. They are equal (=), not equal ( =), less 
than (<), less than or equal (<=), greater than (>)* and 
greater than or equal (>=). 

Examples • 


1. IF A = B THEN 


. . . • 
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2. UNLESS X = Y THEN 

3, IF CHARACTER = 'X THEN - 

6,5* Control Structures and Flow Of Control 


The physical beginning of each control structure, 
except the source program structure, is identified by a 
reserved word specified to the control structure* 


Examples* 

1* FUNCTION 

2. IF 

3. UNLESS 

4* SELECT 

5. REPEAT 

The physical end of each control structure is 
identified by a reserved word specific to the particular 
control structure^- 

t 

Examples • 

1* END (END OF PROGRAM) 

2. END_FUNCTION 

3. END_IF 

4. END__SELECT 

5* END_REPEAT 

Any control structure except a program can be named by 
placing a label on the statement starting the control 
structure. 


Examples 


AS SELECT 
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. x: IF A=B THEN . 

Control structures can be nested to any level. On the 
compiler listing there Is a level count which starts at one 
with the first statement in the source program. The count is 
Incremented each time a control structure is started and 
decremented when the correspond*ng end is encountered. Any 
control structure may appear at any level except the program 
and the function. The program is at level zero. All function 
definition must be at level one. Normal exit from any 
control structure Is made by executing the statement 
physically ending the control structure. Premature exit can 
be made from a control structure by executing a LEAVE 
statement* 

6.5.1. Program Control Structure 

There is no statement which specifically identifies the 
beginning of the program control structure. The END 
statement identifies the physical end of the source program. 
A object program can be terminated by executing a STOP 
statement anywhere in the program or by executing the END 
statement. 

Example^ 

SET X TO 5? 


IF X=r THEN STOP; 
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END_IF; 

END;* * 

6.5*2, FUNCTION Control Structure 

A FUNCTION control structure must be at level one and- 
prior to any reference to the function. The FUNCTION 
statement identifies the start of a function. The FUNCTION 
statement should have a label which becomes the function 
name. 

All variables defined in the program can be referenced 
from within the function and all variables defined in the 
function can be referenced in the main program (storage 
allocation is static). 

Examples 


FUNC: FUNCTION; 

SET I*TO*i+i; 

IF A=B THEN LEAVE FUNC; 

END JF UNCTION; 

A function is invoked by using the name in an 
expression. The function will return a value which will be 
used in the place of function name in the evaluation of the 
expression. The value returned by the function will be the 







value assigned to the function name within the function, 
within the function the function name is treated as a simple 
variable in all contexts, 

FACTOR : FUNCTION(N); 

SET FACTOR TO 1 ? 

REPEAT SET I TO FROM 1 TO N; 

SET FACTOR TO FACTOR *.I ; 

END_R£PEAT ; 

EUDJF UNCTION; 

♦ 

SET X TO FACTOR(G+R*S); 

END; 

The END__FUNCTION statement physically ends a function. 
If the END_FUNCTION is executed, control transfers to the 
point at which the function is invoked. A function can also 
be exited by a LEAVE statement. 

.3. SELECT Control Structure 

The SELECT statement causes a choice to made among 
several possible cases. Each case consists a unique sequence 
of simple statement and/or control structure. 

The choice is made in the following way - 

\ m The expression on the SELECT statement is 
evaluated. 

2. Each CASE statement expression is evaluated in 
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turn until all cases are exhausted or until the select 
expression equals a case expression in value* The matched 
•case is chosen as the one to be executed* If no case is 
matched, none is executed* 

3* After the chosen case is executed, if any, 
execution continues at the statement following the 
END_SELECT. 

The domain (range of statements) for a given CASE is 
from the statement follows the CASE statement to the 
statement which precedes the next CASE statement or the 
END_SELECT statement. 

Example • 

1. SELECT I; 

CASE I; 

CASE 2 ; 

END_SELECT; 

2. SELECT A+B ; 

CASE X+Y ; 

CASE* 5 *; * 

CASE*X+Y+FUN(I) ? 

END_$£LECT*r 

3. SELECT CHARACTER ; 

CASE 'A ; 

CAsi*'3*5 
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CASE ; 

EN0.1sELECT 5 

6.5*4* IF Control Structure 

The IF control structure is started by the IF statement 
by the END_IF statement* 

Examples^ 

1* IF A=B THEN . 

2* IF A+5 = B/C THEN . 

Any number of simple statement and/or control 
structures may follow the reserved word THEN. 

The IF control structure is terminated by the reserved 

( 

word END_IF or the reserved word ELSE. If the ELSE is used, 
it may be followed by a sequence of simple statement and/or 
control structure termi nated by the reserved word END__IF. 

Examples2 

IF A=B THEN 
SET X TO Z ; 


ENDJF ; 
ELSE 

SET Y TO Z 


END IF 5 
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6.5.5. UNLESS Control Structure 

Contrary to the IF statement. In the UNLESS statement 
the sequence of simple statement and/or control structures 
following the reserved word THEN is executed if the 
conditional expression is false. If the conditional 
expression is true, the statements following the ELSE are 
executed. 

Examples^ 

1. UNLESS X=Y THEN SET X TO A+B ; 

ELSE SET X TO C+D ; 

ENDJJNLESS 5 

The UNLESS control structure is terminated by the 
reserved word END__UNLES$ statement. 

6.5.6. REPEAT Control Structure 

The REPEAT control structure is used for forming a loop 
around a sequence of simple statements and/or control 
structures. The REPEAT control structure is terminated by 
the END_REPEAT statements. When the £ND_REPEAT statement is 
encountered during execution, control returns to the 
beginning of the REPEAT control structure. 

The WHILE and SET are two optional phrases for the 
REPEAT statement. The WHILE phrase supplies a conditional 
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expression* The conditional expression is evaluated each 
time the top of the REPEAT is encountered. The sequence of 
simple statement ar\d/o r control structures of the REPEAT is 
executed only if the conditional expression evaluated to 
true. If the conditional expression evaluate to false, the 
REPEAT control structure is terminated and the next 
statement to be executed v? 11 be the one following the 

END_R£PEAT statement. 

* 

Example * 

REPEAT WHILE X<100 ; 


END_REPEAT ; 

The SET phrase specifies a variable referred to as the 
repeat-variable. Each time the top of the REPEAT statement 
in encountered, the REPEAT variable is assigned the,next 
value specified by the SET phrase. 

Example* 

1. REPEAT SET I TO 1, 5, -3, 'X ; 

END_REPEAT 5 

2. REPEAT SET J TO X+Y, X*Y , 

FROM X+5 TO Y*3 BY A/3 , 

FROM 10 TO -100 BY -3 5 


END REPEAT ; 
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3* REPEAT WHILE A>B SET X TO FROM 1 TO 500 
BY 5; 

END*REPEAT; 

The list of values follows the reserved word TO is the 
SET phrase* A list item can be expression or a FROM phrase* 
The FROM, TO, and BY, values can be expressions which 
evaluate to either positive or negative values, if the BY 
value is not specified, the default value is one* 

6.5*7* Termination Statements 

The STOP and the LEAVE are the termination statements 
other than the END statements. The STOP statement causes the 
program to be halted and no further statements will be 
executed. The LEAVE statement names a control structure. 
When the LEAVE' statement is executed, the named control 
structure will be terminated. A LEAVE statement at level N 
can cause termination of any control structure from level 1 
through N-l• 

Example^ 

p: REPEAT WHILE X<1000 ; 

IF X=50*THEN LEAVE P ; 

IF X = 60 THEN STOP; 

END_REPEAT ; 
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CHAPTER VII 


DATA BASES 

7*1. Introduction 

The data bases which are related to the generation of 
machine code are depicted in detail in this chapter. The 
manner in which the various data bases are used is shown by 
Figure i.l in Chapter I, which should now be refered to. 

7.2. SOURCEX 

SGURCEX is an external file built by the SCANNER and 
input by the PARSER. It contains a copy of the card input 
which is the source program of TPL. 

7.3. TOKENS 

TOKENS is an external file built, by the SCANNER and 
input by the PARSER. The entries in the fIle TOKENS are 
numbers which identify a certain token-type followed by a 
variable which may be a pointer to a symbol list entry or a 
number or a null value for those tokens not requiring 
operands. Figure 7.1 shows the three types of entries. 
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1 

J 

TOKEN 

! POINTER ! 


1 

TOKEN 

! NUMBER ! 


I TOKEN ! 

Figure 7.1. - TOKEN ENTRIES 

7.4. Symbol List 

The symbol list Is a one-way linked list. The nodes of 
the list are dynamically allocated as they are needed. Each 
node contains six fields. Nodes are variable In size since 
the NAME field is variable in size. Figure 7.2. Shows the 
layout of a node. 

! NEXT ! 

i ___i 

| TYPE ! DIM OR EF ! 

»_> 

! LOC OR P j 

t_» 

! LNTH ! NAME ! 

I-: ; 

! (VARYING) 

!-! 

FIGURE 7.2. — A SYMBOL NODE 

The field called NEXT Is always a pointer to the next 
entry in the one-way chain, except that the last entry in 
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the symbol list has a value of NULL, a special PL/1(1) 
value* 

» The field called TYPE is an integer value which 
indicates the type of node* TYPE has values for each phase 
of the compilation. The types of nodes built by the SCANNER 
are? 


1 * Label 
'2* Indenti fier 
3* Constant 


The types of nodes recognized by the PARSER are* 

1. Label 

2. Vector 

3. Simple variable 

4. Constant 

5. Function 

6* Active function 
7. Dummy/argument 

The types of nodes recognized by the code generator 

are* 

1. Label 
2* Define label 

3. Vector 

4. SImple vari able 

5. Constant 

6. Function 

7* Defined function 


The field called DIM or EF is filled by the PARSER. For 
a vector DIM contains the length of the vector. For a 
function EF contains a flag indicating whether or not the 
function is external* The field called LOC or P is used by 
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the PARSER and CODEGEN. PARSER uses P when compiling a 
function. If the node is an active function, P is a pointer 
wbfch points to the simple variable where the function value 
is stored. If the node is a dummy argument, P is a pointer 
points to the simple variable where the dummy argument is 
stored. During the storage allocation stage CODEGEN sets LOG 
for vectors, simple variables, or constant. During the 
machine code generation CODEGEN sets LOG for labels or 
functions. 

The field called LNTH is entered when the code is 
allocated. It contains a number which is the length of the 
NAME field In characters. 

The field called NAME is entered when the word Is 

allocated. It contains an identifier which names a label, a 

( 

vector, a simple variable, or a function; or it contains the 
character string which deflns a constant. 

Nodes are allocated by every phase of the compiler. The 
SCANNER builds nodes for every identifier, label, or 
constant found in the source. The PARSER builds nodes for 
temporary storage and system-generated labels. 

The PARSER also builds nodes for function values and 
dummy argument values. Code generator builds a node for a 
system generated label which Is defined at the beginning of 
the executable code. 
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7.5. THREECO 

‘ THREECD is an external file built by the PARSER and 
input to the code generator (CODEGEN). The entries in the 
file THREECD are numbers which identify the type of code 
optionally followed' by one to three pointers or a number. 
All entries in the file have fields for three pointers. If a 
field is not used for a particular code, it is set to NULL 
(a special PL/1 value). Figure 7.3 shows the five types of 
entries in THREECD. 


1 

l 

CODE 

» 






1 

1 

COPE 

j 

i 

NUMBER ! 

-T 

i 

i 

CODE 

i 

i 

POINTER ! 


i 

i 

CODE 

t 

POINTER ! POINTER | 


! 

CODE 

i 

i 

POINTER ! POINTER ! 

POINTER ! 


Figure 7.3..-— THREECD ENTRIES 
Appendix 2 defines the various three address and lists 


their respective operands, if any 
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7.6, RFAIRCD 

RFAIRCD is an externa] file built by the code generator 
and input to the LOADER, which transforms the relocatable 
object code module into an executable module. 

RFAIRCD contains the relocatable object code along with 
the loader control information necessary to load the program 
by the LOADER. Each entry in RFAIRCD consists of a loader 
control character and optionally an operand. The operand can 
be a number or a name. 

Appendix 4 defines the various loader control codes and 
lists their respective operands, if any. 

7.7. ABSBIN 

ABSBIN is an externa] file output from the relocatable 
loader and input to the Fairchild F24 computer, which Is the 
target computer. ABSBIN contains the absolute Fairchild F24 
machine codes which are executed by the Fairchild F24 
computer hardware or by the simulator. 

7.7. ERFORSS and ERRORSP 

ERRORSS and ERRORSP are external files built by the 
SCANNER and the PARSER respectively. Both files contain 
error messages generated during the compilation of a TPL 



program* Both files are merged into the output listing. Each 
entry in the files consists of a line number on which the 
error occurred and up to 100 characters of text describing 
the error. 
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CHAPTER VIII 


SUMMARY AND CONCLUSION 

Tests ng 

SCANNER, PARSER, and CODEGEN will generate a debug 
listing when requested. The debug output options are 
controlled from the source input stream* The options can be 
turned on or off and changed at any point by one source card 
with on column 1 and 2. There are several levels of 

debug output that can be selected. Figure 8.1 shows the 
output for each level. Samples of debug output are shown in 
Appendix 7-13. 

This compiler was tested in several stages* 

Stage 1* SCANNER output was hand-checked using the 
debug output. 

Stage 2* PARSER output was hand-checked using the 
debug output. The PARSER and SCANNER were integrated 
for this stage. 

Stage 3* CGDEGEN output was hand-checked using the 
debug output. CODEGEf'J was i ntegrated wi th PARSER and 
SCANNER for this stage. 

Stage 4* LISTER output was hand-checked using 
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Debug Output Options 


PHASE 

SCANNER 


LEVEL 


OUTPUT 

None. 

Source, Errors 
and tokens. 

Source, errors, tokens, and 
detail trace of finite-state 
machi ne. 


PARSER 


None 

Source, errors, and 
three-address codes. 

Source, errors, three-address 
codes, tokens, and subroutine 
trace. 


CODEGEN 


0 


Source and Fairchild F24 
assembly language listing. 

Source, F24 assembly language 
listing, and object code. 

Source, F24 assembly language 
listing, object code, and 
three-address codes. 
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debug output* LISTER was Integrated with PARSER, 
SCANNER, and CODEGEN for this stage. 

‘ Stage 5- LOADER output was hand-checked using 

debug output* LOADER was integrated with PARSER, 
SCANNER, LISTER and CODEGEN for this stage* 

Stage 6- the TPL compiler was integrated with the 
LOADER and the Fairchild F24 simulator for this stage. 
TPL programs were compiled and executed* The output 
from the Fairchild F24 simulator was hand-checked. 

Test programs for stage 1 though 4 were designed to 
test the compiler rather than go into execution. The 
programs were designed to test each major feature of the 
compiler on a statement by statement basis. Programs for 
stage 5 and 6 were designed to produce output that could be 
intepreted as correct or incorrect depending on whether or 
not the interpretation had been correct. 

Samples of testing programs are shown in Appendix 
14-15. 

8.2. Choice of Implementation Language 

It is believed that the compiler presented in this 
thesis is best Implemented ?n a high-level programming 
language. This language needs not support dynamic arrays or 



data-dlrected ! nput-output; In fact, any feature requiring a 
complex run-time environment Is a II ability. 

The language should make It easy to produce modular 
software systems, that Is, a system containing a large 
percentage of components. In support of this notion, the 
language should posses a reasonable, efficient subroutine 
call facility* Full call-by-name(2) is certainly not needed; 
a simple cal 1-by-reference(2) would be satisfactory. Also a 
programmer should be able to get at out-of-modu1e variables, 
say in a shared data base, without having to go to any great 
trouble. 

A language (especially an implementation language) can 
not afford to hide very many attributes cf the 
target-machine hardware and monitor, as it is difficult and 
dangerous to predict which features will never be useful. 
This implies that perhaps the best Implementation language 
is the one customer-tailored for the target machine 
environment that It must routinely deal with. So we have two 
alternatives* 

1) Define a reasonably machi ne-i independent 
language and hope for the best with regard to monitor 
interfacing and complete instruction-set utilization. 


or 



2) Define a language suitable for a fairly large 
family of machine (like UNI VAC 1100s or the IBM 360/370 
line), allow the language to become rather 
machine-dependent, then count on defining a new one 
when it is time to cross family lines. 

Of the two, the first is more attractive from a 
mobility standpoint. The second is more attractive to those 
wishing to exercise very close control over hardware and 

monitor. 

8.3. Evaluation 

Probably most compilers have been written with 

"conversation routines" embedded in and/or called by the 
lexical analyze/( 1 )'. A call to such routines usually occures 
immediately after each token is discovered. Such routines 
usually convert digit strings to some "internal 12 integer 
representation, for example, or if a decimal point is 
'***......... encountered, to some representation of real numbers; or they 

may interpret special characters inside string constants; 
etc. 

All too often the "Internal" representation chosen is 
that of the machine on which the language is initially being 
implemented, with little or no thought that the compiler 
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might later be moved to another machine or be modified to 
generate code for a different machine* Such decisions are 
usually made because of ,f eff icf ency ,, « 

It Is desirable to keep the entire front-end (scanner 
and parser) of the compiler lndpendent of target 
representations, if possible. If constants are translated to 
target representations by the lexical analyzer, tables of 
several different types usually must be maintained and some 
processors that do not need to know those representations, 
nonetheless must be programmed In term of, or around them. 
For example, If constants are converted and an error message 
should relate to one. It must be converted back to source 
representations for printing. 

In summary, the author suggests that the scanner and 
the parser should be Independent of target representations, 
I f possi bl e. 

8.4. Future Research 

In the author's opinion, future research activities lie 
tn the following areas* 

1) In the optimization for the machine code 

(CHAPTER V), the author described various methods for 



generating optimized machine code* Further extensions 
of the present research might include investigation of 
other mechanism on which optimized machine code can be 
generated* 

2) In the design of the TPL compiler, the author 
chose the static storage management for storage 
allocation. Run-tirne storage allocation may be added in 
the future. 

3) In the description of error recovery in syntax 
analysis (CHAPTER II), the author has presented 
deceptions of error recovery, further research might 
include development of repair techniques to transform 
programs containing syntactic errors into programs that 
are both valid and similar. 
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APPENDIX 1 

LIST OF RESERVED WORDS IN TPL 


BY 

IF 

CASE 

INPUT 

ELSE 

LEAVE 

END 

OUTPUT 

ENDJFUNCTION 

REPEAT 

END_IF 

SELECT 

END_REPEAT 

SET 

END_SELECT 

STOP 

END_UNLESS 

THEN 

EXTERNAL 

TO 

FOR 

UNLESS 

FROM 

VECTOR 


FUNCTION 


WHILE 
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APPENDIX 2 THREE-ADDRESS CODES 


CODE OPERAND AND CODE DEFINITION 


ADD P1,P2,P3. 

„ add PI to P2 and store the result in P3. 


CALLO P1, P 2 . 

the function, PI, is invoked and the returned 
result is store in P2. 


CALL1 P1,P2,P3. 

the function, PI, is invoked with argument, 
P2, and the returned result is stored in P3. 


COMPARE_EQ P1,P2,P3. 

if PI is equal to P2, P3 is set to true; 
otherwise, P3 is set to false. 


COMPARE_GT P1,P2,P3. 

if PI is greater than to P2, P3 is set to 
true; otherwise, P3 is set to false. 


COMPARE__GTEQ P1,P2,P3. 

if PI is greater than or equal to P2, P3 is 
set to true; otherwise, P3 is set to false. 


COMPARE_.LT P1,P2,P3. 

if PI is -less than P2, P3 is set to true; 
otherv/i se, P3 is set to false. 


C0MPAREJ.TEQ P1 f P2,P3. 

if PI is less than or equal to P2, P3 is 
set to true; otherwise, P3 is set to false. 


C0MPARE_NEQ P1,P2,P3. 

if PI is not equal to P2, P3 is set to true; 
otherwise, P3 is set to false. 


j DOTIMES PI,P2,P3* 1 

j multiply PI by P2 and store the result in P3. ! 

j DODIVIDE PI,P2,P3* 1 

i divide PI by P2 and store the result in P3. [ 

-J 















APPENDIX 2 


THREE-ADDRESS CODES (CONTINUED) 


!___ „ ____ __... , 

1 CODE 

OPERAND AND CODE DEFINITION 


! END TAC 

No operand 



indicates the end of three-address codes. 


! ENTERO 

PI. 



enter a function by reserving a location PI 



for the return address. 


1 ENTER1 

PI»P2. 



enter a function by reserving a location PI 



for the return address and the argument 



value at P2, the dummy argument. 


i EXIT 

PI. 



exit a function by returning the function 



value, PI. 


1 GO 

PI. 



branch to PI. 


i GO IF FALSE 

P1,P2. 



if PI is false, branch to P2; otherwise,- 


i 

execute next code. 


! GOIF TRUE 

P1,P2. „ 



if PI Is true, branch to P2; otherwise. 



execute next code. 


! IN 

PI. 



input PI. 


! INDEX 

PI,P2,P3. 



calculate the address of PI subscripted 



by P2. Store the resulting address in P3. 


! LOCDEF 

PI. 



label PI is defined at this location. 


j IN 

PI. 



input PI. 



















APPENDIX 2 THREE-ADDRESS CODES (CONTINUED) 


CODE 

OPERAND AND CODE DEFINITION 


MOV 

PI»P2. 



* 

move PI to P2, 



MOV_I 

P1,P2. 




move PI to the location defined by the 
address In P2„ 


MOV I 

P1,P2. 

move the value at the location 
address In PI to P2. 

dl fi ned by 

the 

NEGATE 

P1,P2. 

negate PI and store the result 

In P2. 


OUT 

PI. 

output PI. 



RETJMP 

PI. 

return Indirect through PI 



STOPCD 

no operand 
stop 



SUBSTRACT 

PI, P2, P3 

substract P2 from PI and store 
P3. 

the result 

I n 

XDEF 

PI. 




the entry point to function PI 
PI. 

Is defined 

at 













77 


APPENDIX 3 

BNF SPECIFICATION OF THIS PROGRAMMING LANGUAGE 


<PROGRAM> <PROGRAAIL> 

! <PRGGRAM_HEAD> <PR 0GRAM__TAI L> 

<PRQGRAM_HEAD> <EXTERNALJ3EGLARATIONJ_IST> 

<VECTOR_ DECLARATION LIST> 

<PROGRAM_TAIL>‘ 25 = <SAM£_LEVEL_ $EQU£NCE> END; 
<EXTERNAL_DECLARATION LIST> <EXTERNAL DECLARATION STATEMEN 

! < E XT E R N A L_D EC LARA T IGN_LIST> “ 

<EXTERNAL__DECLARAT ION STATE ME NT> 
<V£CTGR__D£CLARAT IGN_L IST> <VECTOR DECLARATION STATEMENT 

! <vectorj}eclaration_list> 

< VEC TORJDECLARATION_S TA TEMENT> 

<EXTERNALJ)ECLARATION STATEMENT -= EXTERNAL EXTERNAL LIST> 

<EXTERNAL__LIST> 2 2 = <FUNCTION NAME> “ 

! <EXTERNAL LIST> , <FUNCTION_NAM£> 
<VECTOR_OECLARATIGN> -= VECTOR <VECTOR_LIST> ; 

<VECTOR__L IST> -= <VECTOR_SPEC IF ICATION> 

1 <VECTOR_LI$T> , <VECTOR_SPECIFICATIQN> 
<VECTOR__SPEC IF ICAT.ICN> -= <VECTOR> ( <LENGTH> ) 

<VECTOR> :: = < IDENTIFIER> 

<LENGTH> s':= <CONSTANT> 

<SAMEJLEVEL_SEQUENCE> ::= <T£RMINATION_STATEMENT> 

! <SEQUENTION_BLQCK> 

! <SEQUENTIAL_BLOCK> TERMINATION STATEMENT 
<TERMINATION_STATEMENT> —= < ST 0P_S TA TE ME N T> 

! CEAVE_STATEMENT> 

<SEQUENTIALJ3LCCK>/::= <CCNTROLLEDJ3LOCK> 

! <SEGUENTIAL_BLOCK> CONTROLLED BLOCIO 
<CONTROLL£D_BLOCK> <SIMPLE_STATEMENT> 

! <FUNCTION_BLQCK> 
i <SEL£CT__BLGCK> 

! <REPEAT__BLQCK> 

! <IF_BLOCK> 

! <UNLESS_BLOCK> 

! NULL 

<SIMPLE_STATEMENT> 25= <SET_STATEMENT> 

i <INPUT/OUTPUT_STATEMENT> 

<FUNCTION_BLOCK> 22 = <FUNCTION_HEADER> <SAME_LEVEL_SEQUENCE> 

END_FUNCTION; 

<SELECT_BLOCK> 2 := <SELECT_HEADER> <CASE_LIST> END_SELECT; 
<REPEAT_BLOCK>::=<REPEAT_HEAOER><SAMEJJEVEL_SEQUENCE>ENDJlEPEA 
<IFJBLOCK> S2=r <IF_HEADER> <SAM£_LEVEL_SEQUENCE> <IF__TAIL> 
<UNLESSJBLOCK> 2 := <UNLESS_HEADER> <SAME_LEVEL SEQUENCE> 

<UNLESS TAIL> 
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APPENDIX 3 

BNF SPECIFICATION OF THIS PROGRAMMING LANGUAGE 

(CONTINUED) 


<SET_STATEMENT> - = SET <TARGET> TO <EXPRESSIGN> ; 

<TARGET> <VARIABLE> 

<EXPRESSION> <TERM> 

I EXPRESSION? <ADD/SUBTRACT operator> <term> 
<TERM> <SIGNED_OPERAND> _ 

! <TERM> <MULTIPLY/DIVIDE_OPERATOR? <SIGNED OPERAND> 
<SIGNED_OPERAND> <ADD/SUBTRACT OPERATOR> <SIGNED OPERAND> 

I <OPERAND> ~ 

<OPERANO> ::= <CONSTANT> 


! <VARIABLE> 

! <FUNCTION_REFERENCE> 

! ( <EXPRESSION> ) 

<VARIABLE> !!= <SIMPLE VARIABLE> 

<SUBSCRIPTED VARIABLE? 
<SIMPLE_VARIABLE> s:= <IDENTIFIER? 

<SUBSCR IPTED__VAR I ABLE? ::= < I DENT IF IER? ( <EXPRESSION? 
<INPUT/OUTPUT_STATEMENT? :-* = < INPUT STATEMENT? 

! < OUTP UT_S TATE ME NT? 

<INPUT_STATEMENT? INPUT <INPUT LIST? ; 
<OUTPUT_STATEMENT ::= OUTPUT <OUTPUT LIST? ; 

<INPUT LIST? ::= <TARGET? 


<OUTPUT LIST? 


<INPUT_L1ST? 
EXPRESSION? 


<TARGET? 



!y<OUTPUT_LIST? , <EXPRESSION? 
<FUNCTION_HEADER? ti= <FUNCTION_HEADER? ; 

! <FUNCTION_HEAD? EXTERNAL; 

<FUNCTION_HEAD? ::=<FUMCTION_NAME? : FUNCTION(<DUMMY ARGUMENT? 

! <FUNCTION NAME? : FUNCTION ; 

<FUNCTION_NAME? '••= <IDENTIFIER? 

<OUMMY_ARGUMENT? = <IDENTIFIER? 

<FUNCTION REFERENCE? = <FUNCTION NAME? 


! <FUNCTION_NAME? ( EXPRESSION? ) 
<SELECT_HEADER> = SELECT EXPRESSION? ; 

! <SELECT_NAME? SELECT EXPRESSION? ; 
<SELECT_NAME? <IDENTIFIER? 
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APPENDIX 3 

BNP SPECIFICATION OF THIS PROGRAMMING LANGUAGE 

(CONTINUED) 


<CASE_LIST> 2 : = <CASE> 

! <CASE L IST> <CASE> 

! NULL ~ 

<CASE> 2 : = CASE <EXPRESSION> ; <SAME LEVEL SEQUENCE> 

<REPEAT HEADER> 22= REPEAT <REPEAT_SPECIFICATION> ; 

! REPEAT NAMES REPEAT <R£PEAT SPECIFICATION 
<REPEAT_NAME> :s = <IDENT IFIER> ” 

<REPEAT_SP£CIFICATIGN> ss = <SET_PHRASE> 

! < S HIL E_P HR A SE> 

! <WHILE_PHRASE> <SET PHRASE> 

<WHILE_PHRASE> WHILE <CGNDITIQN> 

<SET_PHRASE> :s~ SET <S£T_VARIA8LE> TO <SET LIST> 

<SET__LIST> <VALUEJ_IST> 

! <SET_LIST> , <VALUE_LIST> 

<VALUEJ_IST> * * — <EXPRESSION> 

! <RANGE_SPECIFICATIQN> 

<RANGE__SPEC IF ICATION> = FROM <START> TO <FINISH> 

! FROM <START> TO <FINISH> BY <INCREMEMT> 
<START> * 2zz <EXPRESS ION> 

<FIN ISH> :s- <EXPRESSION> 

<INCREMENT ss~ <EXPRESSION> 

<SET_VARIABLE> s: = <TARGET> 

< IF__HEADER> = IF <CONDITION> THEN 

! <IF NAME> : IF <CONDITION> THEN 
<IF_NAME> <IDENTIFTER> 

<IFJTAIL> 22 = END IF; 

[ ELSE <SAMEJ.EVEL_SEQUENCE> END_IF; 
<UNLESS_HEADER> = UNLESS <COMDITION> THEN 

! <UNLESS_NAME> : UNLESS <CONDITION> THEN 
<UNLESS_NAME> :s= < IDENT IF IER> 

<UNLE$$_TAIL> s2=.-ENDJUNLESS; 

! ELSE <SAME__LEVEL w _SEQUENCE> END_UNLESS; 
<CONDITION> s:= <EXPRESSION> <RELATIQNAL OP£RATOR> <EXPRESSION 
<LEAVE_STATEMENT> LEAVE <BLOCKJM AME> ; 

<BLOCK_NAME> s:_ <FUNCTION_NAME> 

j SELECT_MAME> 

! <REPEAT_NAME> 

! <IF_NAME> 

! <UNL£SS_NAME> 

<STOP STATEMENT :: = STOP; 




APPENDIX 4 


LOADER CONTROL CODES 


CODE | OPERAND| CODE DEFINITION 

A ! Number ] Load the number at current load address. 
! Increment the load address. 


R ! Number 1 Relocate the number by adding to the bias. 
' ] Load the relocated number. 

! ] Increment the load address. 


D j Number \ Define a label at this location by filling 
i | in a chain of references starting at number 

| ] plus bias. 


X i Number i Load the number at the current load address. 
! I This instruction is a reference to an 

i | external function. 

J ! Do not increment the load address. 


blank ! Name \ There is at this location a reference to an 

! | external function. If the function has been 

! ! loaded previously, enter its address in the 

! I address of the instruction at this loactfon; 

! j otherwise, link this reference to the 

] j reference chain. Increment the load address. 


Z | Name | The entry point to an external function is 

J ] defined at this location. Fill in all 

! ] previous references and enter its name•in 

! | the external symbol directory. 


V | | • Reserve number storage locations at this 

| location. Add number to the load address. 


E ! None \ Set bias to load address. 

! ] This is the end of this program. 


! None j This is the end of this load procedure. 
















APPENDIX 5 

TPL COMPILER DIAGNOSTIC MESSAGES (1) 

LINE LEVEL 

OOOI i J j 

0002 1 j ERROR MASSAGES IN TPL j 

0003 1 i } 

0004 I REPEAT SET l FROM I TO 10; 

**********m l SSI NO TO SUPPLIED 

0005 2 IF A > 0 THEN SET A TO 10; 

0006 3 IF A > 20 THEN SET A TO 20 ; END_IF 

0007 * 3 UNLESS A -* 30 THEN SET A TO 40 ; 

* = * FOLLOWING * *■»* 

0008 4 END__REPEAT» 

********** MI 5Sing eno_unless supplied. 

**********M[SSING END__IF SUPPLIED 
0009 1 END_IF; 

**********£XTRA or UNRECOGNIZABLE STATEMENT IS IGNORED 
0010 1 LEAVE NO_SUCH_BLQCK; 

********** LEAVE OF INACTIVE BLOCK INVALID 

0011 1 IF A -*>< B THEN STOP; END_IF; 

**********missing END IS SUPPLIED 





APPENDIX 6 

TPL COMPILER DIAGNOSTIC MESSAGES (2) 


LINE 

LEVEL 


0001 

1 

i 1 

0002 

i 

j ERROR MESSAGES IN TPL 

0003 

1 

1 i 

0004 

1 

VECTOR Z(O); 


#*********I N VALID vector size set TO 1 
0005 1 SET A12 TO 12A; 

NOT FOUND WHERE EXPECTED 
0006 v I SET B TO 5*8+{C-03J; 

**********SEMICOLON NOT FOUND WHERE EXPECTED 
0007 1 WHAT IS THIS ? 

********** ILLEGAL CHARACTER 

**********£XTRA OR UNRECOGNIZABLE STATEMENT IS IGNORED 


0008 

1 

IF A = 8 THEN SET C 

TO LO; 

0009 

1 

REPEAT SET I FROM 1 

TO LO; 

#:*$***#**[5 c; l |\JG 

TO SUPPLIED 


0010 

2 

SET J TO J + t; 


0011 

2 

END; 


##******##ft J | fyjQ 

FND_REPEAT SUPPLIED 





APPENDIX 7 

TRACE LEVEL 1 OF SCANNER 

OUTN TOKEN DEBUG 0 

OUTN TOKEN DEBUG 0 

OUTN TOKEN LINE_NUMBER 2 

2 SET A TO 1 ; 

OUT TOKEN SET 

OUTP TOKEN IDENTIFIER A 

OUT TOKEN TO 

OUTP TOKEN CONSTANT i 

OUT TOKEN SEMICOLON 

OUTN TOKEN' LINE_NUMBER 3 

3 SET B TO A * 3 +2; 

OUT TOKEN SET 

OUTP TOKEN IDENTIFIER B 

OUT TOKEN TO 

OUTP TOKEN IDENTIFIER A 

OUT TOKEN MULTIPLY 

OUTP TOKEN CONSTANT 3 

OUT TOKEN PLUS 

OUTP TOKEN CONSTANT 2 

OUT TOKEN SEMICOLON 

OUTN TOKEN LINE_NUM3ER 4 

4 If 8 > A THEN SET C TO A ; END IF; 
OUT TOKEN IF 

OUTP TOKEN IDENTIFIER B 

OUT TOKEN GT 

OUTP TOKEN IDENTIFIER A 

OUT TOKEN THEN 
OUT TOKEN SET 

OUTP TOKEN IDENTIFIER C 

OUT TOKEN TO 

OUTP TOKEN IDENTIFIER A 

OUT TOKEN SEMICOLON 
OUT TOKEN END_IF 
OUT TOKEN SEMICOLON 

OUTN TOKEN i. I NE_NUMBER 5 

5 REPEAT SET C TO FROM 1 TO B ; 

OUT TOKEN REPEAT 

OUT TOKEN SET 

QUIP TOKEN IDENTIFIER C 

OUT TOKEN TO 

OUT TOKEN FROM 

OUTP TOKEN CONSTANT 1 

OUT TOKEN TO 

OUTP TOKEN IDENTIFIER B 

OUT TOKEN 5EMICOLON 

OUTN TOKEN LINEJMUMBER 6 

6 IF C = 2 * A THEN SET 6 TO C 5 END_IF 
OUT TOKEN IF 

OUTP TOKEN IDENTIFIER C 

OUT TOKEN EQUAL 

OUTP TOKEN CONSTANT 2 

OUT TOKEN MULTIPLY 

OUTP TOKEN IDENTIFIER A 

OUT TOKEN THEN 

OUT TOKEN SET 

OUTP TOKEN IDENTIFIER B 

OUT TOKEN TO 

OUTP TOKEN IDENTIFIER C 

OUT TOKEN SEMICOLON 


APPENDIX 8 

TRACE LEVEL 2 OF SCANNER 


OUTN 

TOKEN 

DEBUG 




QUIN 

TOKEN 

DEBUG 




OUTN 

TOKEN 

L1NE_NUM8ER 



2 


SET A TO 1 

• 

f 



LN « 

2 

STATE = 

1 

CHAR 

a 

LN - 

2 

STATE a 

1 

CHAR 

a 

LN a 

2 

STATE = 

1 

CHAR 

35 

LN a 

2 

STATE a 

I 

CHAR 

=3 

LM = 

2 

STATE a 

I 

CHAR 

a 

LN “ 

2 

' STATE = 

2 

CHAR 

a 

LN = 

2 

STATE =• 

2 

CHAR 

a 

LN a 

2 

STATE = 

2 

CHAR 

a 

OUT ' 

TOKEN 

SET 




LN a 

2 

STATE a 

1 

CHAR 

a 

LN a 

2 

STATE = 

1 

CHAR 

a 

LN a 

2 

STATE = 

2 

CHAR 

a 

QUIP 

TOKEN 

IDENTIFIER 

A 


LN = 

2 

STATE a 

l 

CHAR 

a 

LN a 

2 

STATE a 

I 

CHAR 

a 

LN a 

2 

STATE = 

2 

CHAR 

a 

LN a 

2 

STATE = 

2 

CHAR 

a 

OUT ' 

TOKEN 

TO 




LN = 

2 

STATE = 

1 

CHAR 

a 

LN a 

2 

STATE = 

1 

CHAR 

a 

IN = 

2 

STATE = 

3 

CHAR 

= 

OUTP 

TOKEN 

CONSTANT 


1 


LN = 

2 

STATE a 

1 

CHAR 

a 

IN * 

2 

STATE = 

l 

CHAR 

a 

LN a 

2 

STATE = 

7 

CHAR 

a 

OUT TOKEN 

SEMICOLON 




LN - 

2 

STATE = 

1 

CHAR 

a 

OUTN 

TOKEN 

LINE_NUM8ER , 

'y' 

i 


3 

SET B TO A 

* 3 

+ 25 


LN a 

3 

STATE = 

I 

CHAR 

a 

LN * 

3 

STATE = 

i 

CHAR 

a 

LN a 

3 

STATE = 

1 

CHAR 

- 

LN a 

3 

STATE = 

I 

CHAR 

a 

LN * 

3 

STATE a 

I 

CHAR 

a 

LN a 

3 

STATE = 

2 

CHAR 

a 

LN = 

3 

STATE = 

2 

CHAR 

a 

LN * 

3 

STATE = 

2 

CHAR 

a 

OUT TOKEN 

SET 




LN a 

3 

STATE = 

i 

CHAR 

a 

LN = 

3 

STATE = 

1 

CHAR 

a 

LN « 

3 

STATE = 

2 

CHAR 

a 

OUTP 

TOKEN 

IDENTIFIER 

B 


LN a 

3 

STATE = 

I 

CHAR 

a 

LN a 

3 

STATE = 

1 

CHAR 

a 

LN = 

3 

STATE = 

2 

CHAR 

a 

LN = 

3 

STATE = 

2 

CHAR 

a 

OUT TOKEN 

TO 




LN a 

3 

STATE a 

1 

CHAR 

a 

LN a 

3 

STATE = 

i 

CHAR 

a 

LN = 

3 

STATE a 

2 

CHAR 

a 

OUTP 

TOKEN 

IDENTIFIER 

A 


LN a 

3 

STATE a 

i 

CHAR 

a 


0 

0 

2 



CHARITYPE 

a 

5 

TOKEN 

a 



CHAR_TYPE 

a 

5 

TOKEN 

a 



CHAR_TYPE 

a 

5 

TOKEN 

a 



CHAR_TYP£ 

a 

5 

TOKEN 

a 


s 

CHAR_TYPE 

a 

I 

TOKEN 

a 


E 

CHARETYPE 

a 

I 

TOKEN 

•a 

s 

T 

CHAR_TYPE 

a 

1 

TOKEN 

a 

se 


CHARETYPE 

a 

5 

TOKEN 

a 

SET 


CHAR__T YPE 

a 

5 

TOKEN 

a 

SET 

A 

CHAR_TYPE 

a 

I 

TOKEN 

a 

SET 


CHAR.TYPE 

= 

5 

TOKEN 

a 

A 


CHAR_TYPE 

a 

5 

TOKEN 

a 

A 

T 

CHAR_TYP£ 

a 

1 

TOKEN 

a 

A 

0 

CHAR_TYPE 

a 

1 

TOKEN 

.a 

T 


CHAR_TYPE 

a 

5 

TOKEN 

a 

TO 


CHAR_TYPE 

a 

5 

TOKEN 

a 

TO 

i 

CHAR_TYPE 

a 

2 

TOKEN 

a 

TO 


CHAR_TYPE 

a 

5 

TOKEN 

a 

1 


CHAR_TYP£ 

a 

5 

TOKEN 


1 

• 

• 

CHAR_TYPE 

a 

4 

TOKEN 

'a 

1 


CHAR_TYPE 

a 

5 

TOKEN 

a 

• 

* 


CHAR_TYPE 

a 

5 

.TOKEN 


• 

t 


3 







CHAR_TYPE 

a 

5 

TOKEN 

a 

# 

t 


CHAR_TYPE 

a 

5 

TOKEN 

= 

• 

* 


CHAR_TYPE 

a 

5 

TOKEN 

a 

• 

• 


CHAR_TYPE 

a 

5 

TOKEN 

a 

• 

* 

S 

CHAR_TYPE 

a 

1 

TOKEN 

a 

• 

* 

E 

CHARETYPE 

a 

1 

TOKEN 

a 

S 

T 

CHAR__TYPE 

a 

1 

TOKEN 

a 

SE 


CHAR_TYP£ 

a 

5 

TOKEN 

a 

SET 


CHARJTYPE 

a 

5 

TOKEN 

a 

SET 

8 

CHAR_TYPE 

a 

1 

TOKEN 

a 

SET 


CHARETYPE 

a 

5 

TOKEN 

= 

B 


CHAR_TYPE 

a 

5 

TOKEN 

= 

B 

T 

CHAft_TYPE 

= 

I 

TOKEN 

a 

B 

0 

CHARETYPE 

= 

I 

TOKEN 

a 

T 


CHARETYPE 

* 

5 

TOKEN 

a 

TO 


CHAR_TYPE 

a 

5 

TOKEN 

a 

TO 

A 

CHAR_TYPE 

a 

1 

TOKEN 

a 

TO 


CHAR_TYPE 

a 

5 

TOKEN 

a 

A 


CHAR.TYPE 

2E 

5 

TOKEN 

a 

A 
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TRACE LEVEL 

1 OF PARSER 

85 


GDE8UG 


0 



GLLNO ‘ 


2 


0002 

1 SET A TO 

1 ; 




MOV 

i 

A 



GLLNO 


3 


0003 

1 SET B TO 

A * 3 

+ 2; 



DOTIMES 

A 

3 

T $1 


ADD 

T$I 

2 

T $2 


MOV 

T$2 

B 



GLLNO' 


4 


0004 

1 IF B > A 

THEN 

SET C TO A ; END_IF; 



COMPARERST 

B 

A 

T $1 


GO IF„FALSE 

r$i 

L #2 



MOV 

A 

C 



LOCDEF 

L«2 




LOCDEF 

un 




GLLNO 


5 


0003 

1 REPEAT SET C TO FROM 1 TO B I 



LOCDEF 

L#5 




MOV 

1 

C 



LOCDEF 

L&7 




COMPARE_.LT 

1 

0 

T$2 


GOIF^TRUE 

T $2 

L#8 



COMPARE _GT 

C 

B 

T$3 


GO 

L#9 




LUCDEF 

. L#8 




COMPA RE_.LT 

C 

B 

T$3 


LOCDEF 

L#9 




GGIF_TRUE 

T $3 

L#6 



CALLO 

L«4 




ADD 

C 

1 

C 


GO 

L#7 




LOCDEF 

L#6 




GO 

LM3 




LOCDEF 

L#4 




ENTERO 

L#10 




GLLNO 


6 


0006 

2 IF C = 2 

* A THEN SET B FO C I END IF; 



DOTIMES 

2 

A 

T $4 


COMPARE_EQ 

C 

T $4 

T $5 


GOIF_FALSE 

T $5 

L#12 •• 



MOV 

C 

B 



LOCDEF 

L# 12 




LOCDEF 

L#11 




GLLNO 


7 


0007 

2 END_RE PEAT ; 




LOCDEF 

L#10 




RETJMP 

L#4 




LOCDEF 

L#3 




GLLNO 


S 


0008 

1 STOP; 





STOPCD 





GLLNO 


9 


0009 

i END; 





STOPCD 




9 

EOF 




STORAGE 

T$ 5 


2 


STORAGE 

T $4 


3 


STORAGE 

L#12 


0 




APPENDIX 10 

TRACE LEVEL 2 OF PARSER 


UPTOK 


DEBUG - 

GOEBUG 


0 

UPTOK 


DEBUG 

GLLNO 


2 

0002 I 

SET 

A TO I ; 

UPTOK 

PRGGRAM_TAIL 


LINNUMBER 

S AME_LEV£L_SEQUENCE 
CONTROLLE DEBLOCK 


UPTOK 

5ET_ST ATEMENT 
TARGET 


SET 

UPTOK 


IDENTIFIER 

UPTOK 

EXPRESSION 

TERM 

SIGNED„OPERANO 


TO 

UPTOK 


CONST ANT 

MOV 

FIND_SEMICOLON 


1 

UPTOK 

CONT R0i.LE0_8L0CK 


SEMICOLON 

GLLNO 


3 

0003 1 

SET 

B TO A * 3 + 2; 

UPTOK 


LINE_NUMBER 

UPTOK 

SET_5TATEMENT 

TARGET 


SET 

UPTOK 


IDENTIFIER 

UPTOK 

EXPRESSION 

TERM 

SIGNED_OPERAND 


TO 

UPTOK 


IDENTIFIER 

UPTOK 

SIGNED_OPERAND 


MULTIPLY 

UPTOK. 


CONSTANT 

DOTIMES 


A 

UPTOK 

TERM 

SIGNED_OP£RAND 


PLUS 

UPTOK 


CONSTANT 

ADD 


T$1 

MOV 

FlND_SEMICOLON 


T$2 

UPTOK 

CONI ROLL ED_BLOCK 


SEMICOLON 

GLLNO 


4 

0004 i 

IF 8 

> A THEN SET C 

UPTOK 


LINE_NUMB£R 

UPTOK 

IF^BLOCK 

CONDITION 

EXPRESSION 

TERM 

SIGNED_OPERAND 


IF 

UPTOK 


IDENTIFIER 

UPTOK 

EXPRESSION 


GT 


A 


3 


2 

B 


EMD^IF; 


T$1 


T $2 


APPENDIX II 

TRACE LEVEL 0 OF CODESEN 


0002 i 


R 

LDA 

i 

R 

STA 

A 

0003 

I 

R 

LDA 

A 

R 

MUL 

3 

R 

STA 

T $ 1 

R 

ADD 

2 

R 

STA 

B 

0004 

' l 

R 

LDA 

B 

R 

SUB 

A 

R 

8N2 

L#2 

R 

LDA 

A 

R 

STA 

C 

D 

L#2 


0 

un 


0 005 

1 

0 

L $5 


R 

LDA 

1 

R 

STA 

c 

0 

L#7 


R 

LDA 

0 

R 

SUB 

1 

R 

8P 

L#8 

R 

LDA 

C 

R 

SUB 

B 

R 

STA 

T $3 

R 

8RU 

L#9 

0 

L#8 


R 

LDA 

B 

R 

SUB 

C 

R 

STA 

T $3 

0 

L#9 


R 

LDA 

T S3 

R 

BP 

Ltf6 

R 

BRU 

Lff4 

R 

LDA 

C 

R 

ADD 

1 

R 

STA 

C 

R 

BRU 

L#7 

D 

L#6 


R 

BRU 

L#3 

D 

L#4 


0006 

2 

R 

LDA 

2 

R 

MUL 

A 

R 

STA 

T $4 

a 

SUB 

C 

R 

BNEZ 

PC+3 

A 

LDA 

200 

R 

BRU 

PC *2 

A 

LS 

24 

a 

8NZ 

L# 12 

R 

LDA 

C 

R 

STA 

B' 

0 

L# 12 


D 

L# 11 


ooe 

ST 

2 


SET A TO L ; 

SET 8 TO A * 

IF 8 > A THEN 

REPEAT SET C 


IF C = 2 * A 


ENDUREPEAT ? 


+ 2; 


SET C TO A ; 


TO FROM 1 TO 8 


THEN SET B TO C 
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TRACE LEVEL 1 OF CODEGEN. 

0002 . I SET A TO 1 ; 

R IDA 1 

R STA A 

0003 I SET 8 TO A* 3+2* 

R LDA A 

A +00000002 V 00000001 D 00000001 R 24000011 R 14000010 R 24000010 

R MUL 3 

R STA T$ 1 

R ADD 2 

R STA B 

0004 1 IF B > A THEN SET C TO A ; END_IF; 

R LDA B 

R SUB A 

R 34000013 R 14000007 R 20000014 R 14000012 R 24000012 R 22000010 

R BNZ L*2 

R LDA A 

R STA C 

D L#2 

D L#1 

0005 1 REPEAT SET C TO FROM 1 10 8 ! 


R 

02300000 R 

24000010 

R 

14000015 

D 

00000027 

D 

00000000 

D 

00000000 

D 

L1t5 











R 

LDA 

1 










R 

STA 

c 










D 

L # 7 











R 

LDA 

0 










R 

SUB 

1 










R 

BP 

L#8 










R 

24000011 R 

14000015 

D 

00000000 

R 

24000005 

R 

22000011 

R 

02400000 

R 

LDA 

C 










R 

SUB 

B 










R 

STA 

TS>3 










R 

BRU 

L#9 










D 

L#8 










• 

R 

LDA 

B 










R 

24000015 R 

22000012 

R 

14000004 

R 

01000000 

D 

00000036 

R 

24000012 

R 

SUB 

C 










R 

STA 

T $3 










0 

L#9 











R 

LDA 

T$3 










R 

BP 

L#6 










R 

BRU 

L#4 










R 

22000015 R 

14000004 

D 

00000042 

R 

24000004 

R 

02400000 

R 

01000000 

R 

LDA 

C 










R 

ADD 

1 










R 

STA 

c 










R 

BRU 

L#7 










0 

L If 6 











R 

BRU 

L#3 










R 

24000015 R 

20000011 

R 

14000015 

R 

01000034 

0 

00000047 

R 

01000000 

D 

L if 4 











0006 

2 

IF C 

=s 

2 * A THEN : 

SET B TO C 

* 

END__ IF ? 



R 

LDA 

2 










R 

MUL 

A 










R 

STA 

T$4 










R 

S U b 

C 










D 

00000050 R 

24000014 

R 

34000010 

R 

14000003 

R 

22000015 

R 

02500065 


R BNEZ PC+3 

A LDA 200 







APPENDIX 13 








TRACE LEVEL Z\ ;0F .CODEGEN 






GLLNO 







0002 

l 

SET A 

TO 1 ; 







MOV 


l 


A 



R 

LDA 

1 







R 

ST A 

A 









GLLNO 


3 




, 

0003 

1 

SET B 

TO A * 3 + 2; 







OQTIMES 


A 


3 


T $1 

R 

LDA 

A 







A 

+00000002 V 00000001 D 

00000001 R 

24000011 

R 14000010 

R 

24000010 

ft 

MUl 

3 







R 

STA 

T$ 1 









ADD 


T $ 1 


2 


T $2 

R 

ADD 

2 









MOV 


r$2 


B 



R 

STA 

B 









GLLNO 


4 





0004 

1 

IF 3 > 

A THEN SET C 

TO A ; 

END_Z F; 





COMPARE. 

__GT 

B 


A 


T$i 

R 

LOA 

B 







R 

SUB 

A 







R 

34000013 R 14000007 R 

• 20000014 R 

14000012 

R 24000012 

R 

22000010 



GOIFJFALSE 

T $1 


L #2 



R 

BNZ 

L#2 









MOV 


A 


C 



ft 

LDA 

A 


. 





R 

STA 

C 









LOCDEF 


L HZ 





D 

L#2 










LOCDEF 


un 





0 

in 










GLLNO 


5 





0005 

1 

REPEAT 

SET C TO FROM 1 TO B 

• 

9 





LOCDEF 


\.#5 





R 

02300000 R 24000010 R 

14000015 D 

00000027 

D 00000000 

D 

ooocoooo 

D 

L #5 










MOV 


1 


c 



R 

LDA 

i 







R 

STA 

C 









LOCDEF 


L#7 





0 

L#7 










COMPARE_LT 

1 


0 


T$2 

R 

LDA 

0 







R 

SUB 

1 









GQXF.JRUE 

T $2 


L#8 



R 

BP 

L#8 







R 

24000011 R 140000X5 D 

00000000 R 

24000005 

ft 22000011 

ft 

02400000 



COMPARE. 

-GT 

c 


B 


T$3 

R 

LDA 

C 







R 

SUB 

B 









GO 


L#9 





R 

STA 

T $3 







R 

BRU 

L#9 









LOCDEF 


L#8 





D 

L #8 










COMPARE.. 

.LT 

C 


9 


T$3 

R 

LDA 

B 






• * 

R 

24000015 R 22000012 R 

14000004 R 

01OOOQOO 

D 00000036 

R 

24000012 

R 

SUB 

C 











APPENDIX 14 (Page 1 of 3) 



SOURCE LISTING OF TEST PROGRAM NUMBER 1 

LING 

LEVEL 


o nn i 

i 

j SAMPLE TESTING PROGRAM NO* 1 

0002 

1 

1 

0003 

1 

-™~~---— 

0004 

1 

SET A IQ 1 ; 

0005 

1 

SET B TO 2 ? 

0006 

1 

IF B > A THEN SET F TO 4 ? 

0007 

?. 

END^IF ; 

0008 

* 1 

REPEAT SET C TO FROM i TO 2 5 

0009 

2 

If C = 1 THEN SET 0 TO 6 ; END_IF ; 

0010 

2 

IF C = 2 THEN SET E TO 7 ; END_IF ; 

0011 

2 

END„,REPE AT ; 

0012 

i 

STOP ; 

0013 

1 

end; 
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APPEND IX 14 a Page 2 of 3) 
RELOCATABLE FAIRCHILD 124 MACHINE CODE 
GENERATED FROM TEST PROGRAM NUMBER 1 


A 

OOOOOOOl 

R 

01000000 

V 

0 000 O'0,0:1- 

V 

CGOOCOOl 

V 

OOOOOOOi 

A 

+00000000 

V 

OOOOOOOi 

V 

OOOOOOOl 

A 

+ OOOOOOOl 

V' : - 

^OOOOOOOl 

A 

+00000002 

V 

OOOOOOOl 

A 

+00000004 

V 

OOOOOOOi 

V 

OOOOOOOl 

A 

+00000006 

V 

OOOOOOOl 

A 

+00000007 

0 

OOOOOOOl 

R 

24000010 

R 

14000007 

R 

24000012 

R 

14000011 

R 

24000011 

R 

22000007 

R 

02300000 

R 

24000014 

R 

14000013 

D 

00000030 

0 

00000000 

D 

00000000 

R 

24000010 

R 

14000015 

0 

00000000 

R 

24000005 

R 

22000010 

R 

02400000 

R 

24000015 

R 

22000012 

R 

14000003 

R 

01000000 

0 

00000037 

R 

24000012 

R 

22000015 

R 

14000003 

0 

00000043 

R 

24000003 

R 

02400000 

R 

01000000 

R 

24000015 

R 

20000010 

R 

14000015 

R 

01000035 

D 

00000050 

R 

oioooooo- 

D 

00000051 

R 

2400G015 

R 

22000010 

R 

02500064 

A 

240002.00 

R 

01000065 

A 

0702-2024 

R 

02300000 

R 

24000017 

R 

14000016 

D 

00000065 

D 

00000000 

R 

24000015 

R 

22000012 

R 

02500075 

A 

24000200 

R 

01000076 

A 

07022024 

R 

02300000 

R 

24000021 

R 

• 14000020 

D 

00000076 

0 

00000000 

0 

OOQOOOOO 

R 

01040057 

0 

00000056 

A 

00Q00200 

A 

00000200 

£ 




APPEB'Dlif 14' ■ff’aCje 3 of 3) 
ABSOLUTE FAIRCHILD MACHINE CODE 
GENERATED FROM TEST PROGRAM NUMBER 1 

F24S1M VERSION OF JANUARY 29, 1974 ------ 

OCTOBER 14, 1976 17: 35i09*300. 


NO TRACE PARAMETERS READ- DEFAULT VALUES USED* 

TRACE-LEVEL = 2 
CURRENT EXECUTION TIME * 0 
EXECUTION TIME LIMIT = 3000 


*#* ENTERING LOADER. 

**#200# 

***00000001 01000222 00000000 00000000 00000000 00000000 00000000 00000000 

***00000001 00000000 00000002 00000000 00000004 00000000 00000000 00000006 

, ***00000000 00000007 24000210 14000207 24000212 14000211 24000211 2200020? 

***02300233 24000214 14000213 24000210 14000215 24000205 22000210 02400244 

***24000215 22000212 14000203 01000247 24000212 22000215 14000203 24000203 

#**02400256 01000257 24000215 20000210 14000215 01000235 01000302 24000215 

***22000210 02500264 24000200 01000265 07022024 02300270 24000217 14000216 

***24000215 22000212 02500275 24000200 01000276 07022024 02300301 24000221 

***14000220 01040257 00000200 00000200 00000000 00000000 00000000 00000000 

***00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

***00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

***00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

***00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

***00000000 00000000 OOOOOGOO 00GO0000 00000000 00000000 00000000 00000000 

***00000000 00000000 00000000 OOOOOGOO 00000000 00000000 00000000 GQQQGOOO 

***00000000 OOOOOGOO 00000000 00000000 00000000 OGOOOOOO 00000000 00000000 

***00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

***00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

***00000000 00000000 COOOOOOO OGOOOOOO 00000000 00000000 00000000 00000000 

***00000000 00000000 00000000 00000000 00000000 00000000 0.0000000 OOOOOGOO 

***00000000 00000000 00000000 00000000 00000000 OOOOOGOO 00000000 00000000 

***00000000 00000000 00000000 00000000 00000000 OOOOOGOO OOOOOGOO 00000000 

***00000000 QOQGGQGG 00000000 OGOOOOOO 00000000 00000000 00000000 00000000 

***00000000 00000000 OOOOOGOO 00000000 OOOOOGOO OOOOOGOO 00000000 00000000 

*** 201 ## 

*** LEAVING LOADER WITH PC=00000010000001 ERROR.t.EVEL= 0 


* ERROR LEVEL IS 0 


* DUMP.C 

* DUMP.COUNT = l 

* INITIAL SAVE OF MEMORY. 


* END OF DUMP C 




LINE 


0001 

0002 

0003 

0004 

0005 

0006 

0007 

0008 

0009 

0010 

0011 

0012 

0013 


APPENDIX 15 (Page 1 of 3) 

SOURCE LISTING OF TEST PROGRAM NUMBER 2 


LEVEL 


1 

1 

1 

1 

1 

2 
2 
2 
2 
2 
2 
2 
1 


| SAMPLE TESTING PROGRAM PROGRAM NO* 
SET B TO 0 ; 

REPEAT SET A TO -ltO»I 5 
if A < 8 THEN SET XX TO 1 ; END_IF 

IF A <=B THEN SET XX TO 2 ; END_JF 

If A •= B THEN SET XX TO 3 ? END..IF 

IF A -»=B THEN SET XX TO 4 ; ENO_IE 
IF A >~B THEN SET XX TO 5 i END_IF 

IF A > B THEN SET XX TO 6 ; END..IF 

END_REPEAT ; 

end; 
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APPENDIX 75 (Page' 2 of 3) 
RELOCATABLE FAIRCHILD F24 MACHINE CODE 
GENE-RATED FROM TEST PROGRAM NUMBER 2 


A 

OOOOOOOl 

R 

0100GOOD 

V 

00000 001; 

V , 

OOOOOOOl 

V 

OOOOOOOl 

V 

OOOOOOOl 

A 

+00000000 

V 

OOOOOOOl 

A 

+00000001 

V 

OOOOOOOl 

A 

+00000002 

A 

+00000003 

A 

+00000004 

A 

+00000005 

A 

+00000006 

0 

OOOOOOOl 

R 

24000006 

R 

14000005 

D 

00000000 

R 

24000010 

R 

22000010 

R 

22000010 

R 

14000003 

F< 

14000007 

R 

0.1000000 

0 

00000000 

R 

24000006 

R 

14000007 

R 

01000026 

0 

00000000 

R 

24000010 

R 

14000007 

R 

01000031 

Q 

00000000 

R 

01000000 

0 

00000034 

R 

24000005 

R 

22000007 

R 

02300000 

R 

24000010 

R 

14000011 

D 

00000040 

0 

00000000 

R 

24000005 

R 

22000007 

R 

02400050 

R 

02100050 

A 

24000200 

R 

02300000 

R 

24000012 

R 

14000011 

0 

00000050 

D 

00000000 

R 

24000007 

R 

22000005 

R 

02500060 

A 

24000200 

R 

01000061 

A 

07022024 

R 

02300000 

R. 

24000013 

R 

14000011 

D 

00000061 

D 

00000000 

R 

24000007 

R 

22000005 

R 

02200070 

A 

24000200 

R 

02300000 

R 

24000014 

R 

14000011 

S3 

00000070 

D 

00000000 

R 

24000007 

R 

22000005 

R 

02400100 

R 

02100100 

A 

24000200 

R 

02300000 

R 

24000015 

R 

14000011 

0 

00000 LOO 

D 

00000000 

R 

24000007 

R 

22000005 

R. 

02300000 

R 

24000016 

R 

14000011 

D 

00000105 

D 

00000000 

0 

00000000 

R 

01040036 

0 

00000035 

A 

00000200 

£ 
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APPENDIX 15 (Page 3 of 3) 
ABSOLUTE FAIRCHILD F24 MACHINE CODE 
GENERATED FROM TEST PROGRAM NUMBER 2 
F24SIM VERSION OF JANUARY 29* 1974 - ~ - — - 
OCTOBER 14, 1976 17:33:46*970 


NO TRACE PARAMETERS READ. DEFAULT VALUES USED * 

TRACE-LEVEL - 2 
CURRENT EXECUTION TIME ~ 0 
EXECUTION TIME LIMIT * 3000 


❖ ** £NTBRING L0ADER* 

*** 200 # 

***00000.001 01000217 00000000 00000000 00000000 00000000 00000000 00000000 

***00000001 00000000 00000002 00000003 00000004 00000005 00000006 24000206 

***14000205 2.4000210 22000210 22000210 14000203 14000207 01000236 24000206 

***14000207 01000236 24000210 14000207 01000236 01000311 24000205 22000207 

***02300243 24000210 14000211 24000205 22000207 02400250 02100250 24000200 

***02300253 24000212 14000211 24000207 22000205 02500260 24000200 01000261. 

***07022024 02300264 24000213 14000211 24000207 22000205 02200270 24000200 

***02300273 24000214 14000211 24000207 .22000205 02400300 02100300 24000200 

***02300303 24000215 14000211 24000207 22000205 02300310 24000216 14000211 

***01040236 00000200 000000.00 00000000 00000000 00000000 00000000 00000000 

***00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

***00000000 00000000 00000000 00000000 00000000 OOOOOGOO 00000000 00000000 

***00000000 QOOOOOOO 00000000 00000000 00000000 00000000 00000000 00000000 

***00000000 00000000 QOOOOOOO 00000000 00000000 00000000 00000000 00000000 

***00000000 QOOOOOOO QOOOOOOO QOOOOOOO 00000000 00000000 00000000 QOOOOOOO 

***00000000 00000000 00000000 00000000 00000000 QOOOOOOO 00000000 00000000 

***00000000 00000000 QOOOOOOO 00000000 00000000 00000000 QOOOOOOO 00000000 

***00000000 00000000 00000000 QOOOOOOO 00000000 QOOOOOOO 00000000 00000000 

***00000000 00000000 OOOOOGOO OOOOOOCO 00000000 00000000 00000000 00000000 

***00000000 QOOOOOOO OOOOOGOO 00000000 00000000 00000000 00000000 00000000 

***00000000 00000000 00000000 00000000 00000000 QOOOOOOO 00000000 QOOOOOOO 

***00000000 00000000 QOOOOOOO QOOOOOOO 00000000 QOOOOOOO OOOOOGOO 00000000 

***00000000 QOOOOOOO QOOOOOOO QOOOOOOO OOOOOGOO OOOOOGOO OOOOOGOO 00000000 

***00000000 00000000 00000000 00000000 OOOOOGOO OOOOOGOO QOOOOOOO 00000000 

***201## 

*** LEAVING LOADER WITH POOOQQQOIQOOOOOI ERROR_LEVEL> 0 


* ERROR LEVEL IS 0 


* DUMP_C 

* DUMP_CQUNT = 1 

* INITIAL SAVE OF MEMORY * 


* END OF DUMP_C 
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